home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
United Public Domain Gold 2
/
United Public Domain Gold 2.iso
/
utilities
/
pu296.dms
/
pu296.adf
/
AmigaBBS
/
BUGS1.TXT
< prev
next >
Wrap
Text File
|
1989-01-01
|
6KB
|
125 lines
P1111.BUGS
Oh heck, there are always bugs. I can run my own programs for years and
never see a bug, but give it to someone else and XAPPO! Many of these
have been fixed, some are not really bugs, others are not caused by program.
1. There is a bug where the TNC reconnects to the other station after the
other station disconnects. This can happen when there is data left in the
TNC buffer after the disconnect, and it seems the TNC reconnects so that it
can complete the transmission. KA2BQE says this is a bug in the AX25L2V2
protocal and that the NETROM writers saw this and invented their own
protocol. Never been able to duplicate the reconnect when AX25L2V2 was
turned off, so he may be correct.
2. FULL-DUPLEX TNC operation. This is when your TNC starts transmitting,
and you know by listening to the packets that it should be receiving. On
the Kantronics KAM, I found this happened when MAXUSERS or (USERS?) was
set to 0/1. Didn't care if FULLDUP parameter was on or off.
3. Header time changes EST to UTC. Re-assemble to change. Argh!
4. The garbage on the screen when a station disconnects. OK, the
disconnect sequence has been the real tuffy on this BBS thing. I am still
studying all the numerous ways a disconnect can screw up, and the junk is
the only way I can watch what happens. Most of it will be eliminated at
some future revision.
5. When used as a terminal on packet, in the monitor mode (F5 toggled on)
I keep thinking that it misses the first line of a message on occasions.
Must have looked for this bug 20 times, and keep drawing a blank. Me thinks
that this bug doesn't exist.
6. New message overwrites older message. Happens when you delete a message
from the top of the DIR. The BBS looks at the first 4 bytes of DIR and
uses that number as the last message number used, adds 1 to it and writes
the next message under this new number. Can't see an easy way around this,
the answer for now is to not delete the top entry in DIR.
7. Kantronics PBBS forward. Not a bug because this works, both on older
and newer Kantronics PBBS's. This BBS sends SP WA3MNT < N3ET @ BBS
and this format works, but is not the 'standard' for forwarding (assuming
there is a 'standard').
8. PRMBS (a la KA2BQE). Forwarding works, but you never know what BQE is
gonna do on his next PRMBS revision. Forwarding may look strange at times
when TO or FROM a PRMBS, but I've never seen a forward fail.
9. *** ERRORS. This BBS will tend to disconnect when it sees an ERROR
message. Well, better this then carry on for hours sending WHAT, HUH, or
INVALID COMMAND. Also, there may be a case where this BBS sends a
*** ERROR message, then sends a prompt '>'. Still watching for this.
The prompt may cause the other end to think a message was properly forwarded.
10. F9 BBS disable. There may be a problem if you have the BBS disabled
and someone connects and the terminal part times out, causing the BBS to
be enabled for the next connect. I gotta see if I can force this.
11. HELP-KEY - Press this a second time before first completes, lose stack.
12. NETROM. If you connect to EPA, then tell EPA NETROM to connect
to KB3UD, you think you are connected to KB3UD. No. You are connected to
EPA, not KB3UD. BBS picks up on correct call from NET/ROM, TheNet, and
KA-NODES and works OK.
13. NETROM. Set your FRACK and DWAIT a little higher if you get too many
collisions with AX25L2V2 polls.
14. MESSAGE disconnects. Someone starts a message and disconnects. If no
text has been entered, the BBS looks dead. Give it 256 seconds ~4 minutes
to time out.
15. MESSAGE too big. This BBS has a safety switch that stops saving a
messsage after 65k. You will have no indication of this. The counters
and all are capable of many gigabytes, but my computer isn't.
16. CAPTURE too big. The terminal part has a safety switch thats stops
capturing after 1.8 megabytes (+/-). Seemed a good number for my 3 megabyte
RAM. I think this was deleted ??
17. MESSAGE forward. A lot of TNC STATUS lines go to the screen when the
BBS forwards a message. The BBS looks for # (busy) C (connected to)
D (Disconnected) etc. Again, this is useful debug info.
18. #ELK connection. The TNC won't allow this (C #ELK).
19. RM returns with error when no message for you.
20. *** DISK FULL. Another PRMBS special. I think this BBS will disconnect
when it sees this message. If it don't, then it is a bug.
21. SP WA3MNT N3ET. BBS will not recognize N3ET, nor report the error.
22. CMD: HUH eh?. You may get 50 of these in a row. Happens when someone
tries to connect and doesn't copy you. BBS retries out, sees another
connect, and gets confused. Takes a while, but BBS should recover.
23. USR file corrupted. Usually drops everything but call, then gets wrong
name on next user. I've had this happen after pushing PANIC BUTTON, F10,
when BBS was active. Also happens with disk errors or messed up B:USR.
24. DIR file corrupted. Only saw this happen when SYSOP faked an entry
without correct number of spaces. If you get lost, have another BBS or
person send you a message like SP WA3MNT @ KA3JAI < WB3HVJ then look
at what the BBS did in the DIR.
25. B:BID sometimes messes itself. New B:BID with old pointer. Fixed??
26. LIST NONE. If nothing to list, 'L' command just prompts.
27. Amiga DIR command. You get a GURU if you use DIR RAM: OPT I
and then type 'T' on a file that BBS is writing to.
28. NO MEMORY. Gimme a break, if you run out of memory or DISK space,
the AMiga should (will) tell you about it. I don't know how to handle
this cause I never let it happen.
29. STACK 8000. BBS really needs about 1000 byte stack or less.
I run with STACK 8000 in my S/Startup-Sequence file.
30 ICONS. I don't. So the BBS don't either. Sorry, but you rodent fans
hafta learn CLI. Read this => you can't use the MOUSE to run the BBS from
WORKBENCH.